home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d8 / protocol.arc / PROTOCOL.TXT < prev   
Encoding:
Text File  |  1991-01-02  |  7.3 KB  |  156 lines
  1.  
  2. PROTOCOL.TXT   Author unknown.  Some addl comments by T. McCormick: 01/91.
  3. ---------------------------------------------------------------------------
  4.  
  5. This is a brief summary of asynchronous protocols commonly used for send-
  6. ing and receiving files with personal computers.
  7.  
  8. Sending files from one computer to another involves some sort of checking
  9. to insure that the receiving end gets only what was sent.    This usually
  10. involves the use of some "protocol" or handshaking. This is a set of rules
  11. and signals performed in concert by both ends.    Hence both ends must be
  12. using the same protocol!
  13.  
  14.  
  15. =-=-=-=-=-=-=-=-=-=-=   ASYNCHRONOUS PROTOCOLS   =-=-=-=-=-=-=-=-=-=-=-=-=
  16.  
  17. When transferring files via a PC using a modem and a communications program,
  18. it is necessary to select one protocol for use at both ends.
  19.  
  20. Different communications packages support different transfer protocols so
  21. you will need to check your documentaion to determine which protocols your
  22. communications package supports.
  23.  
  24. Following is a brief description of the most commonly used PC protocols.
  25.  
  26.  
  27. ASCII DATA CAPTURE (... not truly a protocol, but widely used.)
  28.  
  29. NOTE:  You MAY NOT transfer a binary file (such as a .COM or .EXE file)
  30.        using this method!  You MAY NOT tranfer compressed files such as
  31.        .ZIP or .ARC files either. ASCII may only be used for small text
  32.        files where data integrity is not important.
  33.  
  34. ASCII transfer is simply the sending of textual information, and is
  35. limited to 7 bit information.  This excludes all characters above 127
  36. decimal such as the IBM PC graphics characters.  It may be used for small
  37. text files over clean telephone lines.  If data integrity is required,
  38. this method should NOT be used, or if used, the file should be sent twice
  39. and received as different filenames so that they can be compared with some
  40. utility such as COMP which comes with DOS.
  41.  
  42. The transfer of files in ASCII mode can be done if your system is capable
  43. of any type of data capture.  Just be aware that data may be dropped or
  44. garbage characters may be added from line noise during the transfer. Since
  45. no error checking such as a checksum or block length is being done, you
  46. are at the mercy of the irregular quality of phone transmission and
  47. switching equipment.
  48.  
  49. ASCII is presented here even though it is not truly a "protocol". Even if
  50. the XON/XOFF (Control-S - Control-Q) signals are respected by both ends
  51. to prevent overruns, and the eighth bit is used for parity checking, the
  52. user has some aid, but not really enough.
  53.  
  54.  
  55.  
  56. KERMIT
  57.  
  58. This protocol's main claim is not speed, but rather its ability to interact
  59. with many types of computers from mainframes to micros.  It can cope with
  60. systems limited to seven-bit characters even when the data to be transmittted
  61. is in eight-bit form.  All characters to be sent are translated into standard
  62. printable characters and reconstructed on the receiving end.  While not
  63. terribly efficient, it is sometimes an absolute necessity for data transfer
  64. involving different types of systmes and terminal types.  It is not
  65. recommended for PC to PC transfers.
  66.  
  67.  
  68. XMODEM and XMODEM/CRC
  69.  
  70. Xmodem is a file transfer protocol originally developed by Ward Christensen. 
  71. There are two basic type of XMODEM protocols, XMODEM and XMODEM/CRC.  Xmodem
  72. offers the advantage of error checking on a block by block basis to assure
  73. that the data sent contains no errors.  It does this by adding a checksum byte
  74. to the end of each 128 byte block of data; the receiver calculates its own
  75. checksum and compares it to the one received.  If an error is detected in the
  76. transmission, XMODEM will request that the sending PC retransmit the block of
  77. data.  In addition to the above checksum comparison, XMODEM/CRC adds another
  78. level of error detection using a complex CYCLICAL REDUNANCY CHECK algorithm.
  79.  
  80. XMODEM and XMODEM/CRC are slow protocols compared to many others available
  81. but they are quite reliable and available in almost all communications
  82. packages.  They should only be used when you software supports no other
  83. protocol.  XMODEM/CRC is preferrable to XMODEM due to its greatly improved
  84. error checking.
  85.  
  86.  
  87. 1K-XMODEM
  88.  
  89. This protocol performs exactly like regular XMODEM/CRC, but increases the
  90. block size to 1024 bytes, hence the name 1K.  It is slightly faster (on fairly
  91. clean phone lines) than regular XMODEM due to a smaller number of blocks being
  92. sent, and therefore fewer block checks being made.
  93.  
  94. 1K-XMODEM/G
  95.  
  96. This version of 1K-XMODEM makes use of MNP hardware error correction to do
  97. away with the block-by block checking in the normal version.  The result is a
  98. very fast single file transfer  protocol for use if YMODEM/G is not readily available.
  99.  
  100.  
  101.  
  102. YMODEM
  103.  
  104. YMODEM is a protocol devised by Chuck Forsberg of Omen Technology which adds
  105. enhancements to portocol based transfer.  He is the author of DSZ and PRO-YAM
  106. communications products.  These are mature and robust file transfer programs.
  107. YMODEM block sizes are variable at 128/1024, but 1K (1024) is the usual size.
  108. Error checking makes use of CRC-16, accurate to 99.99%.  By definition, all
  109. YMODEM transfers are capable of sending multiple files at one request, with
  110. the file size and date included in the "header block" sent prior to each
  111. file.  YMODEM supports multiple file transfer (both down and up) of up to 50
  112. files om a "batch".
  113.  
  114. CAUTION:  A number of communication programs incorrectly use the term
  115.           YMODEM but actually send using 1K-XMODEM.  This practice is
  116.           not proper and will result in a failure when used with a
  117.           true YMODEM transfer.
  118.  
  119. Use of YMODEM, if supported by a caller's software is recommended over
  120. XMODEM and 1K-XMODEM for speed, reliability and features.
  121.  
  122.  
  123. YMODEM/G
  124.  
  125. This variation of YMODEM is usually only available when callers are using
  126. modems supporting MNP (Microcom Networking Protocol) or the U.S. Robotics
  127. ARQ hardware error checking.  MNP is a hardware based system in which the
  128. modems perform the actual error checking and correction, if needed.   The
  129. software simply sends the information blindly from one system to the other
  130. using the protocol for block sorting information only.  YMODEM/G is among
  131. the fastest protocols with the exception of the newer versions of ZMODEM.
  132. YMODEM/G also supports multiple file transfer (both down and up) of up to
  133. 50 files per "batch".
  134.  
  135.  
  136. ZMODEM
  137.  
  138. Use this protocol if it is available at both ends.  As of 1991, it is the
  139. protocol of choice for asynchronous file transfers.  It is solid, widely
  140. used, and fast.
  141.  
  142. ZMODEM is another protocol developed by Chuck Forsberg of Omen technology.
  143. It is a "streaming protocol", one which sends variable sized blocks of data
  144. with CRC-32 error checking for an accuracy of 99.9999%, but does not wait
  145. for an acknowledgment from the receiving computer.  The sending system
  146. assumes data received is OK unless a repeat request is sent for a specific
  147. block.  This streaming activity makes ZMODEM one of the fastest protocols
  148. available.
  149.  
  150. ZMODEM supports multiple files transfer capability.  This is commonly 
  151. referred to as "batch transfers".  ZMODEM also has the unique capability
  152. to resume file transfers that have been aborted for some reason and thus
  153. only partially completed.  This crash recovery facility is usually not
  154. needed, but is very handy when it is.
  155.  
  156. ---------------------------------------------------------------------------